I was sitting down with a couple of my fellow programmers after a long day of testing our new online shopping cart, and we asked ourselves a very important question:
Why don’t most science fiction books get the feel of programming right?
If you’re not a programmer, you’ll doubtlessly protest: “There’s a lot of programming in speculative fiction!” But there isn’t, actually. What there is is a lot of is hacking, which is to say breaking into established systems, usually with a lot of muttered techno mumbo-jumbo like “I’m in the mainframe!” while hopelessly-inept thugs spray the area with bullets.
Now, there’s nothing wrong with hacking. (One of my favorite series, The Murderbot Diaries, features a cyborg killing machine who loves both soap operas and hacking into cameras, so Murderbot is certainly well-balanced.) But programming involves the act of creation, of fine-tuning, of project management—none of which traditionally lend itself to an captivating narrative.
So I asked: What are the core activities of programming, and which stories come closest to getting it right?
Maintenance
What Happens When You’re Maintaining A Project: Every day you arrive at work to look at a list of bugs that your customers have discovered, sorted by priority. You go down the list, from most important to least important, and try to fix each of them in turn.
These are usually not terribly exciting bugs. Which is good. You don’t want the exciting bugs, which tend to be things like “You know that salary information our program was supposed to keep confidential? Well, it didn’t.” And you get to hunt through code trying to find the error while the vice president of your company (salary $140k annually, plus three weeks vacation) calls up and screams in your ear.
No, most bugs are mild, obscure things like “User is logged out every Thursday at 10:13 pm.” If you’re lucky, you patch a widespread inconvenience with a two-line fix and look like a genius. If you’re not, you’ll be sitting there on Thursday at 10:13 pm, hoping you can see the bug so you can fix it—which is known as “the dreaded repro,” short for “Cannot reproduce the bug,” which is programmer-speak for “That doesn’t happen when I do it, so who knows what’s happening?”
Maintenance is, generally, tedium. The code is well known. The problems are low-key. Not exactly high stakes stuff.
So what novel best feels like maintaining code?
Max Gladstone’s Three Parts Dead
Buy the Book
Three Parts Dead
Three Parts Dead is technically about magical law—but it turns out that “magically-enforced laws” turn out to have a lot of overlap with “programming,” even if the protagonists think of themselves as contract negotiators.
The novel starts out with the exciting kind of bug—Kos Everburning has been found dead by his priesthood for no reason that anyone can understand, and the junior partner and the new developer are sent in to investigate. It turns out that what’s happened to Kos Everburning is very much a bug in every (computerized) sense of the term, and much of the novel concerns itself with forms of data recovery—or, more accurately, retrieving the contracts that fuel a god’s power.
Three Parts Dead isn’t about the mild kind of maintenance—but then again, slow bug-fixing would probably make a lousy book. And there’s a lot more horrible gargoyles and soul-sucking shadows and vampires than you’re likely to encounter in troubleshooting your Apache stack.
But close enough.
Legacy Code
What Happens When You’re Working On Legacy Code: This code has been around longer than you’ve been alive, and it will be around long after you’re dead. And like all ancient things—including cars, plumbing, and people—legacy code has quirks you have to work around lest you encounter its ire.
The trick to legacy code is that it is, by definition, the most vital code in your program. People use it every day, and they can’t not use it, so altering legacy code is like doing heart surgery. On a jogger. Who refuses to stop jogging while you’re doing heart surgery on them.
Everyone knows the legacy code is bad. Half your job consists of facing teams of management who brightly say, “Well, it should be easy to…” while you explain—without looking like you’re stonewalling them—that in fact, that this trivial fix will require eighteen months of resources minimum because some obscure limitation of the legacy code (the portion of code nicknamed “the dream crusher”) is the entire reason we can’t have nice things.
What you don’t tell them is that even if they approve the eighteen-month project, their fix will in fact probably never get implemented, because the legacy code has outlasted previous teams of management, and will outlast them, and will probably outlast the heat death of the universe.
So what novel best feels like working on legacy code?
Vernor Vinge’s A Deepness in the Sky
Buy the Book
A Deepness in the Sky
Honestly, most of A Deepness In The Sky doesn’t involve legacy coding—it’s a sprawling space opera about first contact and a culture of Spiders in the throes of their own scientific revolution, and a great big juicy hatesink of a villain.
But when I talked to other programmers, what they remembered was Vinge’s profession of the programmer-archaeologist, whose whole job was sifting through aeons-old code to try to understand what all of this mysterious infrastructure does, hunting through the archives to extract and resettle useful programs.
There’s even a hidden wink to Unix timestamps in there—indicating that long after humanity has spread across to the stars, we’ll still be marking our time (as many computers today) as the seconds elapsed since midnight on January 1st, 1970.
All the way to the heat death of the universe.
Building Long-Term Projects
What Happens When You’re Building Long-Term Projects: At one point, the projected failure rate of massive IT projects was around 50%; now, with much better management structures and development skills in place, that failure rate is down to around 15%.
Still. Those Russian roulette odds means signing onto a long-term project is an act of faith.
There’s a good chance that you will pour your best programming art into this project, only for it to fail for reasons that were by no means your own. Maybe management figures out halfway through that what you built isn’t actually what they needed. (Non-programmers are astonishingly incoherent when it comes to explaining what they want, and often demand you to do the exact opposite of what they need.) Maybe another manager takes over and doesn’t believe in your project, so he starves it of resources until you dwindle to dust. Maybe some other company devises a better solution, and they abandon you to buy that.
Every line of code you write is a hope. (Quite often, that hope is that you will slay the dreaded Legacy Code.) But you don’t write a lot of code; instead, you hold endless meetings with other programmers, debating weighty theories as to how this complex thing should function, getting bogged down in minutiae that actually do matter, but every moment spent in these necessary arguments is running out the clock.
Some days you feel like you’re programming a dream—that you’re wrestling with more of an idea than an outcome.
So what novel best feels like building long-term projects?
Kij Johnson’s The Man Who Bridged the Mist
Buy the Book
The Man Who Bridged the Mist
There is a vast river of mist that separates an empire. A man wants to build a great bridge to join the two halves.
That’s pretty much the story.
Kij Johnson’s prose is always dazzling and sparse, and her mastery has never been more on form than in this novella, which isn’t so much about code as it is that sense of immensity you feel, looking straight on at something that is so monumentally difficult that you might never finish it. And Kij is very precise in describing the elements of building, the huge influx of resources it will take to accomplish this task.
It’s not about programming in the physical sense; despite the title of “software engineer,” building a bridge isn’t much like creating a program at all. But The Man Who Bridged The Mist is very much about that sense of wonder, of sweat, of politics—all the things that must come together to create the impossible.
Being Dazzled By New Interactions
What Happens When You’re Joining Things Together: Wanna know the trick about programming? No individual part is all that difficult.
Don’t understand how one website calls another to get information? You could learn that in an afternoon. Want to know how a database stores your password safely? That’s like two hours. How to get words in a browser to render in bold, italic, or superscript?
Fifteen minutes. Seriously.
But programming does require expertise, because while no individual portion tends to be indecipherable, it’s putting them all together that requires many overlapping knowledge bases. Putting together a website that allows you to log in requires knowledge of how websites talk to each other, and storing passwords, and getting words to render the login form—but there’s so much more you need on top of that to get it to function.
What’s happening is that you are assembling a Justice League together from your own skillsets, piling on all the little aptitudes you’ve gained along the way until you can create something magnificent by fusing these modular skills into one project.
And then—if you’re lucky—some hotshot programmer comes along and shows you how you can spin three plates in tandem to make your code do something you never thought it could do before, something more powerful and intoxicating and whoa we are flying high on the narcotic of our own tech.
So what novel feels most like being dazzled by new interactions?
Robert Jackson Bennett’s Foundryside
Buy the Book
Foundryside
As is usual with fantasy books that evoke programming, there’s a lot more magical ninjas involved than you’re likely to see scanning Stack Overflow. But the flourishing tech start-up economy of Bennett’s steampunk city of Tevanne is fueled by scrivings—magical instructions that alter reality. And a plucky kid is tasked with stealing an important artifact that, of course, is more than it appears.
But what Bennett nails in this book is that feeling of technology stacking upon itself. The magic follows rules, and the rules are clear, but the ramifications are not fully thought through. And there’s multiple times when the characters face down impossible uses of scriving that, when broken down, not only seem plausible, but almost downright inevitable in how they got used.
Plus, you know, there’s a whole criticism of the merchant houses that rule the city, and what that refined capitalism-as-cult does to the power structure. So if you want a little critique with your intrigue, well, here y’go.
Terrible Documentation
What Happens When The Documentation Sucks: It feels like there should be a fantasy series that handles this, because you never feel more like a D&D Wizard learning a new spell than when you’re poring over someone else’s half-assed documentation.
Except the wizards in books all have this admirable commitment to documenting every aspect of their spells so others can learn them safely. Whereas the code that actual programmers write tend to be like 18th century cookbooks, where they assume with a frightening confidence that you already understand how much suet goes in a blood pudding so we’re just not gonna talk about that.
Or the documentation is about that pie you desperately need to bake, except that they’re not making the pie using an oven or a pie tin, no, these people have a kitchen that only uses an air fryer that you’ve never heard of and they bake their pies in a pile of natural coal, but you sort of hope it’s the same principles so it’s pie time, mofos.
Or you follow the documentation note-for-note, levelling up your baking skills until you understand this Bakewell tart so thoroughly that you’re sure Paul Hollywood himself would give you a handshake over it, only to discover that they’ve discontinued that brand of Bakewell tart and the new children 3.0 won’t eat it.
Plus, wizards in stories are smart. They generally don’t type in inscrutable commands we found on our servers in the hopes that this doesn’t actually summon a demon (or, in our case, install a malicious daemon on our hard drive). They’re never pretty sure they understood most of what’s happening here, and what they understood fixed the code so far, so time to do the old cut-and-copy and call response code YOLO.
Which is not to say there’s not some attention paid to bad documentation in magic, but the books tend to be “The wizard goofed up the spell,” not “This spellbook was written by disinterested wizards who just wanted to get the bare minimum down before they went off for some pipeweed.”
So what novel feels most like when the documentation sucks?
No winner.
I’m not saying there isn’t one—I’m merely saying that I haven’t read it. I’m sure you all have suggestions in the comments.
But those books need to look a lot like this XKCD homage to DenverCoder9.
Technology Changing Society
What Happens When Your Technology Takes New Root: Technology is like memes; the greatest sign of success is that people start messing with it.
And when they mess with your technology, if you’re lucky, your users will find uses for it that you never considered. Twitter was originally seen as a glorified group chat—nobody thought that it’d become the main method for Black Lives Matter groups to propagate evidence of police brutality. Flickr (a photo website sadly waning in influence now) started off as a way to share screenshots on a MMORPG. Heck, in its early stages, the Internet was basically seen as a way to store documentation.
Every technology that takes root evolves in unpredictable ways. And when truly life-changing technology hits, it transforms society. That’s a responsibility that every programmer needs to face up to—the same code that makes it easy to check in on your kids can become a way for an abusive partner to lock their spouse into misery. And let us not forget the astounding cruelty that can take place when an unthinking coder decides that “User engagement” is the same thing as “Happiest post of the year!” and decides to drag out a father’s dead daughter as the top post in their year in review.
(RIP, Rebecca Alison Meyer, forever embedded in the Internet as #rebeccapurple.)
So what novel feels most like technology changing society?
Ramez Naam’s Nexus
Buy the Book
Nexus
Nexus is the first in a trilogy, but trust me, you’ll want to read the whole thing. Because it deals what happens when programmers perfect the Nexus OS—an operating system that ties directly into your brain.
This is not a unique take. But what makes Nexus so relentlessly unique is the way that the brain-hacking keeps spiraling into new hands, and those hands in turn change what the Nexus OS is for. Governments want to use it for both surveillance and control, obviously, but they see it as a threat to freedom. The hackers—or at least the Burning Man-flavored hackers presented here—see it as an opportunity, or a drug, or the possibility for unique forms of psychotherapy.
None of them are wrong.
What Naam does in this book is astounding, in a science-fiction book: he doesn’t really seem to have an opinion. Is Nexus good? Bad? Neutral? That all strictly depends on who’s using it, and even the characters change their opinions on Nexus as the world begins to shape and adapt to it.
When you look at something like the Internet, it’s been both a force for unalloyed good and an enabler of seething evils. Nexus would be exactly the same. And here, in the Nexus trilogy, technology is allowed to be a reflection of human growth, not the seed-bed for a moralizing author tract.
The Group Chat Experience
What Happens When You Have To Deal With Patch Notes: In an ideal world, your fellow programmer would be your ally. But often, your fellow programmers are the opposition—adding trivial bugs they should have caught, rewriting perfectly good code to fit their own pedantic standards, ignoring the big warning sign that says “PLEASE DO NOT OPEN THE CAGE WITH THE FACE-EATING LEOPARDS” shortly before filing a ticket that says “Face eaten, pls help.”
So you have long threads devoted to What Not To Do, and then people argue about What Should Be Done, and it’s tedious and bureaucratic and yet somehow necessary.
So what novel feels most like dealing with patch notes?
Desmond Warzel’s “Wikihistory”
Gonna be honest; I made this category just because I still love this story.
It’s not a novel. It’s about, what, 2,000 words max? But it honestly does feel like this. Promise. And it’s amusing as all hell.
Users Forming Cargo Cults
What It’s Like To Find Your Users Contorting Themselves Into Pretzels Over A UI Bug You Could Have Fixed In Twenty Minutes: Remember when I said that non-programmers are routinely very bad at knowing what they want, and ask for massive solutions that don’t actually fix their problem?
Welp, there’s a flip side to that: people who treat anything computerized as though it were set in stone.
Now, this generally doesn’t apply to customers; they’re an odd mix of continually demanding and dead-as-the-void silent. But if you develop software for an office, the people at that office will often assume that this is all management will allow them to have.
Your software will become the thing they have to work around, and they’ll never tell you.
If you’re not careful, you’ll find entire cultures warped around a feature you could have knocked off in an afternoon. Secretaries will mail each other spreadsheets of invoice numbers that they looked up, painfully, one by one, when you could have literally added one control to the search bar. Clerks will enter in forty-digit gift certificates on a keypad because nobody thought to ask for a scanner.
And you will walk in to stammer, “That—no. You don’t have to—we could—“ And somewhere in the back of your mind you will be tallying all the hours lost to this worship of The Software, and wonder how soon you can rescue these poor, benighted souls from their own faith.
So what novel feels most like finding your users contorting themselves into pretzels over a UI bug you could have fixed in twenty minutes?
No winner.
Again, I’m not saying nobody’s written this book, I’m merely saying that I haven’t found it. Please, sound off.
But personally, I’d love to read some behemoth of a novel detailing an oppressed civilization rebelling against a malicious AI, and at the end of it some dude from QA comes in and says, “Oh, yeah, we can patch that” and fixes it in a weekend.
Optimization
What It’s Like To Optimize Your Computers: If you’ve ever spun up a computer with Linux installed, you know there’s an overwhelming amount of options that you can tweak. You can go blind staring at a thirty-page manual that documents the options for a single command… let alone the options on the four hundred or so other commands.
Sure, the defaults are probably good. And maybe even secure, if you’ve found a Linux distro that’s user-friendly.
But what if you really need to fine-tune that server until it sings? What if you’re spinning up a web server that needs to handle 50,000 users connecting all at once? What if you’ve got a ton of complex data, and you need to make sure your data storehouse is optimized to return answers to any query under 15 milliseconds?
Well, then you’re gonna take such a deep dive into the documentation that you risk getting compression sickness. You’re gonna trawl forums, check Stack Overflow, drop into Slacks and Discords to ask the experts. There are people who are paid to do nothing but make computers run sleeker, harder, better, faster—and if you want to get there, you’re going to have to have a fundamental understanding of the keepalive timeouts and the proxy caches.
So what novel feels most like dealing with optimizing your computers?
Ferrett Steinmetz’s Automatic Reload
Buy the Book
Automatic Reload
Full disclosure: I wrote this book, so, you know, take my recommendation with the mandated grain of salt.
That said, I wrote this book as a programmer who was very curious about what cybercombat would be like in the future—because eventually, when real-time computer image processing gets to be quick and reliable enough, there will come a day when the computer can outdraw and fire our slow, tired human reflexes.
At which point, everything will come down to optimization. Because once you remove the human element from warfare, well, what’s that mean for programmers when your default settings were lax enough to accidentally fire upon an innocent child?
That’s where Mat, the hero of Automatic Reload, is right now: he’s a hulking cyborg with prosthetic armaments, and he has emerged from a blink-of-an-eye combat to realize that his guns have killed the wrong person. As such, he’s become obsessed with fine-tuning, ensuring all the maintenance he does will never again harm a bystander no matter what firefights might erupt, and that mechanized PTSD is slowly killing him.
Fortunately, he finds the right girl to help talk him out of his trauma.
Unfortunately, she’s also a genetically engineered killing machine.
Bad management
What It’s Like To Have Bad Management As A Programmer: Want to know one of the nicest things a good manager can say to you?
“I know this is a terrible solution. It’s tech debt, and we’ll regret it later. But our CEO needs a fix this week, not in six months, so get to it.”
That sounds weird—you’d rather have a manager who could stop you from rolling out terrible solutions, right? And you do. But that’s not always possible; sometimes outside forces require sub-par hotfixes, and sometimes the solution you really want is too expensive (in terms of man-hours or hardware) to accomplish.
When that happens, good managers bite the bullet and acknowledge the troubles.
Bad managers gaslight you.
Bad managers will tell you whatever upper management wants is an ideal solution, why would you argue, you’re overreacting. Bad managers will come down with mysterious cases of amnesia when, after you’ve told them time and time again that this duct-tape-and-glue fix is unstable, then they blame you for not warning them when that hotfix collapses.
Bad management is shortsighted. Bad management undermines you, because your very realistic complaints are an impediment to the fantasy view of reality they’re desperately trying to peddle to their superiors. Bad management views your spare time as their time.
And despite all that, sometimes bad management gets it done. Because other people will work their asses off for love of the dream.
So what novel feels most like dealing with having bad management as a programmer?
Not Charlie Stross’ The Atrocity Archives.
I’ve heard you champing at the bit. Every time anytime mentions “programming” and “speculative fiction,” the words “CHARLIE STROSS’ ATROCITY ARCHIVES” erupts from their mouths like the Deep Ones crying out to their undersea master C’thulhu.
And I mean, who doesn’t like the idea of hackers working in a government bureaucracy, fighting Lovecraftian monsters? Charlie Stross does an excellent job capturing the detail of finely scientific explorations of gorgon stares, otherworldly dimensions, and—gack—unicorns.
(You really don’t want to know what perfidity can be wreaked with a Strossian unicorn.)
That said, I’d argue that the Atrocity Archives is more akin to hacking. There’s a lot of programming thought going into it, but even though Bob Howard’s bosses are notably bad (including some literally inhumanly awful management), I think there’s a slightly better choice for this:
Mary Robinette Kowal’s The Calculating Stars
Buy the Book
The Calculating Stars
The Calculating Stars—the first in the Lady Astronaut series—starts off with a bang.
More specifically, the bang that ends the Earth.
But of course it’s not quite that simple—the meteorite that hit us in this alt-history 1950s story has destroyed our ecosystem, but it’s a slow burn. Eventually, Earth will become uninhabitable, and as such the world has to come together to establish a spacebound colony.
Elma York is a prodigy: a master mathematician, an experienced pilot, dedicated and competent. But Elma York is also a Jewish woman, in the 1950s, participating in a space program that only values her because she’s a good photo op. She’s trying hard to work past her panic attacks to get a working space program up and running… But her upper management is undermining her at every opportunity, and actively working against the integration of Elma’s friends and coworkers.
The Calculating Stars is a good example of what happens when a manager is devoted to the project, but not necessarily to you. There’s plenty of dressing-downs, of sidelining the most talented people for political reasons, of wasting resources to prioritize the “good” solutions they know of.
(Good solutions that usually turn out to be overwhelmingly white and cismale. Go figure.)
As I said, bad management doesn’t always destroy a project. Sometimes they succeed regardless. And in The Calculating Stars, you can see some very human managers—people who care very deeply about their project, but they have some blind spots, and they have some things they’re absolutely unwilling to hear.
Which honestly, seems about the truest depiction of tech I can imagine.
Ferrett Steinmetz is a graduate of both the Clarion Writers’ Workshop and Viable Paradise, and was nominated for the Nebula Award in 2012, for his novelette Sauerkraut Station. He is the author of the novels The Sol Majestic from Tor Books, as well as the ‘Mancer trilogy and The Uploaded. His short fiction has been featured in Asimov’s Science Fiction, Beneath Ceaseless Skies, Shimmer, and Andromeda Spaceways Inflight Magazine. Ferrett lives in Cleveland with his wife.
